The present disclosure relates to a client and a server in a supervisory control and data acquisition system, and, more particularly, to a client and a server in a supervisory control and data acquisition system where a screen specification of an executed screen is registered in the server to prevent overlapping processing for identical requests from multiple clients to reduce a load of the server, and, further, to optimize data processing of the server in a response to the client request based on the registered screen specification.
A conventional supervisory control and data acquisition (SCADA) system may monitor and control a remote equipment in a centralized manner. For this, in the SCADA system, a server and a client may communicate collected data with each other and then based on the collected data, the remote equipment may be controlled.
Specifically, in the SCADA system, the sever may acquire data from the remote equipment and then store the data in a real-time database (RTDB). The client may request the server of data to be displayed on a supervisory screen, and then, in a response to the request, the server may retrieve the requested data from the real-time database and fetch the data therefrom and then send the same to the client. The client may display the data from the server on the supervisory screen, and may supervise the remote equipment.
FIG. 1 shows a view for illustrating a communication between a client and a server in the conventional SCADA system.
The SCADA system 100 may include a server 110 to receive and process a data request from clients 121, 122, and 123, and the clients 121, 122, and 123 to send the data request to the server 110 and, in a response to the receipt, to display the data on a supervisory screen thereof.
In the SCADA system 100, for a command and data service between the server 110 and clients 121, 122, and 123, a data service module 112 may be used. To be specific, when the clients 121, 122, and 123 execute screens, the clients 121, 122, and 123 may request the data service module 112 of the server 110 data to be displayed on the executed screen. In response to the data request, the data service module 112 may look into the real-time database (RTDB) (not shown) and fetch the searched data and process the fetched data into request-satisfying data to be sent to the clients 121, 122, and 123. In this connection, the clients 121, 122, and 123 may display the received data on the screen. Further, the clients 121, 122, and 123 may send commands such as value setting, tag setting, etc. via the data service module 112 to the server 110 of the SCADA system 100 or an on-field equipment in a power station, etc.
The server 110 may individually process data requests from each of the multiple clients 121, 122, and 123. In this connection, when the clients 121, 122, and 123 may execute the screen, the clients may request the server 110 data to be displayed on the executed screen one time or periodically. Further, there may be a plurality of clients 121, 122, and 123. If the N number of the clients 121, 122, and 123 execute the same screen, the server 110 may process the N numbers of the identical data requests individually and then send the N times-individually processed data to each of the clients 121, 122, and 123.
As shown in FIG. 1, when all of the client 1 121, client 2 122 and client 3 123 execute the same “screen 1”, each of the clients 121, 122, and 123 may request the data service module 112 of the server 110 “data of the screen 1”. Then, the data service module 112 may individually process “data of the screen 1” requested from the clients 121, 122, and 123 and send the individually-processed data to each of the client 121, 122, and 123. This procedure may be repeated periodically.
FIG. 2 shows a flow chart of a method of a server processing a data request from a client in the conventional SCADA system.
The server 110 may receive a data request S201.
In this connection, the data request may be about data to be displayed on the executed screen executed by each client 121, 122, and 123. The server 110 may receive the data request from each client 121, 122, and 123.
The server 110 may allocate a data space S202.
To be specific, the server 110 may secure a memory space for data processing in order to process the data request from each client 121, 122, and 123 and may dynamically allocate the secured memory space for the data processing.
The server 110 may process the data request S203. To this end, the server 110 may look into the real-time database and fetch associated data and write or read the fetched data into or from the memory space to form data to be sent to each client 121, 122, and 123.
Thereafter, the server 110 may send a data processing result to each client 121, 122, and 123 S204.
Upon completion of sending of the data processing result, the server 110 may de-allocate the data space S205. In this connection, the de-allocated memory space may be allocated for another task.
This procedure may be repeated periodically and per a request from each client 121, 122, and 123.
Currently, the server may repeat the identical processing N times for the N number of the identical requests in processing the data request from the client. Further, the client may typically execute the data requests periodically. Thus, the sever may perform N times dynamic allocations of the processing space, N times data processing, and N times de-allocations of the allocated processing space for the N number of the identical data requests for a single period, and, then, repeat N times dynamic allocations of the processing space, N times data processing, and N times de-allocations of the allocated processing space for the N number of the identical data requests for a next single period.
Thus, the server may have increased load for the data processing, and increased load for the dynamic allocation and deallocation of the processing space and thus increased cost thereof.